a t e v a n s . c o m

I want to make a game with haxe. I am following my friend Travis’ tutorials but there are a few peccadillos I feel are worth noting. Here’s my experience getting going:

1. Do not use Homebrew to install haxe on OS X. Use the downloadable installer. Here’s why. Download from here - not anywhere else.

2. I could not find in the docs / tutorials / getting started’s any examples of actually running haxe or haxelib or whatever except for here. No one thinks explaining the command line interface is important - I guess everyone’s using IDE’s? Anyway, here’s my command:

    nme test /Users/you/path/to/project/project.nmml mac -debug -Dfdb
   

3. Immediately got Standard Library not found :/ Fix by adding this to your shell script:

    export HAXE_LIBRARY_PATH="/usr/lib/haxe/std/:/usr/lib/haxe/lib/"
   

4. libraries to install:

    haxelib install nme
    haxelib install flixel
   

5. Next up:

    Error: No developer directory found at /Developer.
   

   Building for mac os x native. XCode doesn’t set up this directory any more when you install via the App Store. Solution here

    sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer
   

6. Crash!

    Couldn't set OpenGL mode:
    Sep 16 18:07:53 yourcomputer.home project[10076] Warning: CGDisplayBaseAddress is obsolete and returning NULL for display 0x7bd8d23f`
   

   Solution - in /project.nmml change this:

    <window width="0" height="0" fps="30" orientation="landscape" fullscreen="true" unless="target_flash" />
   

   to this:

    <window width="640" height="480" fps="30" orientation="landscape" resizable="true" unless="target_flash" />
   

   It’s a bug in SDL, as per this discussion

7. Go to

    /Applications/TextMate.app/Contents/SharedSupport/Bundles
   

   and run

    git clone https://github.com/jdonaldson/HaXe.tmbundle.git
   

   to install the Haxe TextMate bundle. Don’t forget to tell TextMate to reload bundles.

After all that I finally got a compiling window.

    # Usage: in develoopment.rb
    #
    #   config.middleware.insert_before Rails::Rack::Logger, DisableAssetsLogger
    #
    class DisableAssetsLogger
      def initialize(app)
        @app = app
        Rails.application.assets.logger = Logger.new('/dev/null')
      end
    
      def call(env)
        previous_level = Rails.logger.level
        Rails.logger.level = Logger::ERROR if env['PATH_INFO'].index("/assets/") == 0
        @app.call(env)
      ensure
        Rails.logger.level = previous_level
      end
    end

Props to Marc Cournoyer - found via StackOverflow

/^((\d+[%@]?)|(x\d+)|(\d+x\d+[!^<>@]?))$/

That’s what I got. Anything better? Holla at me!

Update

Looks like Thoughtbot uses this matcher in paperclip:

# Parses a "WxH" formatted string, where W is the width and H is the height.
def self.parse string
  if match = (string && string.match(/\b(\d*)x?(\d*)\b([\>\<\#\@\%^!])?/i))
    Geometry.new(*match[1,3])
  end
end

server {
  listen         [::]:80;
  return 301 https://$host$request_uri;
}

via ServerFault

Hex Picker OS X extension

Been using this for years, and it’s great.

via Rambling Labs

Found this to be pretty useful. Now to get nginx errors working nicely…

The thing is that we found out that Capistrano was failing because apparently it had lost track of the commit SHA, hence the error message:

“Could not parse object “b4042”

We found deleting the “cached-copy” inside the shared directory, to have made this go away at least for now.

via Ikenna Okpala

Most of the big JavasScript chart libraries don’t do radar charts. And even if they did, for just doing a radar chart you don’t want to set up a whole blessed charting library for just one thing.

This is a simple, easy solution, and with a bit of customization, it looks great. +1

coffee-script-tmbundle

A TextMate Bundle for CoffeeScript — Read more

via Github

Useful if you’re going with Rails3 defaults. Ultimately I decided CoffeeScript was one layer of indirection too many for me. I’m sticking with plain .js and jQuery for now.

I spent the last month on the Caribbean coast in Costa Rica, largely working on Jekyllhub. Hey, don’t hate, I sunburn at the drop of a hat. My swimming / beach watching was done entirely at sunrise & sunset. If you’re interested, you can check out my photos here.

The area of coast I was on had very low bandwidth. Most of the restaurants that advertised Wifi had a single 3G card or dongle they used to run the wireless network. I found two places with DSL lines, both of which were hostels not too keen on having interloping developers. The 3G dongle I managed to get was slow at best, and utterly unreliable about half the time. So most of trying to develop there was an act of more patience than I really have - type in a bash command into a remote terminal, wait ten seconds for it to show up, hit enter, wait again, watch results, debug. It gives me a real appreciation for when server time was a prized university asset, and you had to hand your cards or programs over to other people to be run.

Here’s a bunch of things I found really useful to stay off the internet as much as possible while developing my project. Some of these are probably obvious, but maybe you’ll see something new. And even if you have a good internet connection, the speed of local resources is incredible. It’s nice to have even though I’m back in civilization.

1. yard server -g the yard gem gives you great documentation for all your ruby gems. I set this to run nohup in the background on an unused port and made an entry in /etc/hosts so it’s easy to get to.
2. yard for ruby core / ruby stdlib - bookmark the static files and you’re good to go
3. jqAPI - jquery documentation in the style of YARD. Since it’s super ajazzy and doesn’t work with the file:// protocol, I had to pull some hacks to get it to work. It runs on a jekyll server in nohup / background mode with a /hosts alias.
4. Twitter Bootstrap comes with local documentation; you just have to remember to put it somewhere.
5. GMail basic html really is a lot faster than regular GMail on a flaky connection, and it handles timeouts better.
6. Facebook Mobile looks really nice in a narrow second window, and runs a lot better on an unreliable line than normal, full-sized facebook does.

All that provided basically all the local documentation I needed, and a few ways to connect with other folks to talk about issues and whatnot. Hope it helps someone else out there! -